SPF, DKIM and DMARC for the Domain You Actually Send From

A while ago I wrote about locking down the domains you don’t send email from. Three DNS records and you’re done. Your main domain, the one your team and your invoices actually send from, is harder. Get it wrong and your own quotes land in spam. Leave it alone and anyone can send email that claims to be you.

Here’s the plain-English version of SPF, DKIM and DMARC, and a safe order to set them up.

The three records, in one sentence each

• SPF lists which servers are allowed to send email for your domain.
• DKIM puts a signature on each email, so the receiver can check it really came from you and wasn’t changed on the way.
• DMARC tells receivers what to do when an email fails those checks, and asks them to send you reports about it.

SPF and DKIM prove things. DMARC is the part with teeth.

Why it’s not optional any more

Since February 2024, Google has required everyone sending to Gmail addresses to have at least SPF or DKIM set up, and anyone sending more than 5,000 messages a day to have SPF, DKIM and DMARC. Yahoo brought in matching rules at the same time, and Microsoft followed for Outlook.com in 2025.

The standard itself was updated too. In May 2026 the IETF published a new version of DMARC, RFC 9989. Existing records keep working (they still start with v=DMARC1), and nothing in this guide changes. The main difference for SPF: DMARC now only checks SPF against your envelope sender, the hidden “MAIL FROM” or bounce address, and no longer falls back to the name the sending server introduces itself with.

You might not send 5,000 emails a day. But your newsletter tool, your booking system and your accounting software all send as you, and receivers judge the domain as a whole.

Step 1: list everything that sends as you

This is the step everyone skips, and it’s why DMARC projects break things. Write down every service that sends email with your domain in the From address. Typically:

• your mailboxes (Microsoft 365 or Google Workspace)
• your website’s contact form and notifications
• newsletters (Mailchimp and friends)
• invoices and quotes (Xero, MYOB, QuickBooks)
• CRM, booking, help desk and e-commerce tools

Don’t worry if you miss one. Step 4 will find it.

Step 2: one SPF record, done properly

Each service tells you what to add, usually an include:. They all go in one TXT record. Two SPF records is the most common mistake we see, and it makes both invalid.

v=spf1 include:spf.protection.outlook.com include:spf.your-invoicing-tool.example -all

(The first include is Microsoft 365’s. The second stands in for whatever your other services tell you to add.)

Watch the limit. The SPF standard, RFC 7208, allows at most 10 DNS lookups per check. IP addresses don’t count, only the parts that make the receiver look something up:

• Counts: include:, a, mx, exists:, redirect= and ptr (don’t use ptr at all), including the ones hidden inside other services’ includes. A bare a or mx counts too, because it looks up your own domain.
• Free: ip4:, ip6: and all.

Go over 10 and SPF stops working for every email you send, not just the ones from the extra service. Unless DKIM is set up (step 3), DMARC fails with it. You’ll sometimes hear that some mail providers are lenient about the limit. Don’t count on it: the standard says receivers must stop at 10, and we haven’t found a major provider that documents doing otherwise.

There’s a second, lesser-known limit: no more than two lookups that come back empty. These are usually include:s for services that have shut down or moved. The standard only says receivers should enforce this one, so they differ, and that’s exactly why you can’t rely on getting away with it. Clean out includes for tools you no longer use.

Still over? “SPF flattening” tools replace includes with the IP addresses behind them. It works, but when a provider changes its addresses your record goes stale, so only use a tool that keeps it updated automatically.

Step 3: turn on DKIM for every service

DKIM isn’t always on by default. In Microsoft 365 and Google Workspace you have to switch it on and add the records they give you (usually a CNAME or TXT under selector._domainkey). Most newsletter and invoicing tools have a “verify your domain” or “authenticate your domain” page that does the same.

DKIM matters more than SPF for DMARC, because it survives forwarding. If a service can’t do DKIM with your domain, think twice about letting it send as you.

Does that mean SPF is on the way out? No. Gmail, Yahoo and Outlook.com still require it from bulk senders, and the 2026 DMARC standard still uses it. But its job is smaller than it used to be: it only covers the envelope sender, and it breaks as soon as an email is forwarded. Treat SPF as required, and DKIM as the thing that actually keeps your email passing.

Step 4: DMARC, starting gently

Start with a policy that changes nothing, just collects reports:

TXT  _dmarc  "v=DMARC1; p=none; rua=mailto:[email protected]"

Receivers will start sending you daily reports listing every server that sent email as your domain, and whether it passed. The raw reports are XML and not much fun to read, so use a tool. If your DNS is on Cloudflare, its DMARC Management feature is available on every plan and turns them into a readable list of senders.

Leave it for two to four weeks. Look for legitimate services that fail, and fix them (usually missing DKIM). Look for things you don’t recognise. Those are either a forgotten tool, or someone pretending to be you.

Step 5: tighten it

When the reports show your real email passing, move up in steps:

1. p=quarantine: failing email goes to spam. Watch for complaints for a couple of weeks.
2. p=reject: failing email should be refused outright. This is the goal.

At p=reject, someone sending a fake invoice “from” your domain gets bounced at the door by most big providers, instead of landing in your customer’s inbox looking exactly like you.

Note the “most”. p=reject is a request, not an order. Each receiving mail system decides what to do, and the 2026 DMARC standard actually tells receivers not to reject on your policy alone but to weigh it against their own checks, because forwarded email and mailing lists can fail DMARC innocently. In practice:

• Gmail, Yahoo and Outlook.com act on it and bounce most failing email.
• Microsoft 365 business accounts have an “Honor DMARC record policy” setting in their anti-phishing policy. With it on, failing email is refused. Their admin can turn it off or add exceptions.
• On-premises Exchange Server, including Exchange 2019 and the current Subscription Edition, has no DMARC checking built in. Unless the business has a filtering service in front of it, your policy is ignored.

So p=reject stops most fake email, not all of it. It’s still well worth doing. Just don’t promise your customers that spoofing is impossible.

Keep it working

Whenever you add a new tool that sends email, add it to SPF and set up its DKIM before it sends a single message. And keep an eye on the reports. A new, unknown sender in your DMARC reports is worth a look. It’s in the same spirit as reviewing your trusted IP Lists: security settings drift unless someone checks.

Want us to look at your email records, or take you from p=none to p=reject without breaking anything? Get in touch.