Monday morning. Your bookkeeper calls a client to ask why last month's invoice still hasn't been paid. "We never received any invoice," they reply. Ten minutes of digging later, they find it in the spam folder. A week later, another client asks why you emailed them new bank details — and you sent nothing. The two incidents look unrelated, but they often share the same root cause: your domain has no proper DMARC setup, and no correct SPF and DKIM records to go with it. The result is poor email deliverability and a domain anyone can impersonate.

In this article we explain in plain language what the three technologies are, why the big mailbox providers now require them, and how to roll them out step by step without breaking your own email.

Signs your domain has an email authentication problem

If any of these situations sound familiar, it's worth checking your domain's DNS records:

Quotes, invoices and payment reminders land in clients' spam — especially at Gmail and Outlook.com
Messages from your website's contact form don't arrive, or go to "Junk"
Your newsletter has an unexplainably low open rate
Clients or partners receive emails "from you" that you never sent
You get bounces with codes like 550 5.7.x mentioning failed authentication

The reason is simple: email was designed decades ago with no built-in way to prove who actually sent a message. Anyone can type office@yourcompany.com into the "From" field. SPF, DKIM and DMARC close exactly that gap.

SPF, DKIM and DMARC — what each one proves

The three technologies don't replace each other — they work as a team. Think of them as three separate checks on every message.

SPF — who is allowed to send on your behalf

SPF (Sender Policy Framework) is a TXT record in your domain's DNS that lists the servers and services authorized to send mail for that domain. When a receiving server accepts a message, it checks whether it came from an address on that list. An example for a company using Microsoft 365: "v=spf1 include:spf.protection.outlook.com -all". For Google Workspace the include is "include:_spf.google.com".

DKIM — a digital signature proving the message wasn't forged

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The public key is published in DNS, and the recipient uses it to verify that the message really was signed by your domain and wasn't altered in transit. Every service that sends on your behalf needs its own DKIM key.

DMARC — the rule for what happens when checks fail

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two checks to the address the recipient actually sees in the "From" field. A message passes DMARC if SPF or DKIM passes and the domain that was checked matches the one in "From" (this is called alignment). The DMARC record tells receivers what to do with messages that fail — nothing (p=none), quarantine to spam (p=quarantine) or reject (p=reject) — and where to send reports. Example: a record named _dmarc.yourcompany.com with the value "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com".

Why this is no longer optional

In February 2024, Google and Yahoo introduced mandatory sender requirements. According to Google's guidelines, anyone sending to personal Gmail addresses must have at least SPF or DKIM, valid DNS records and a low spam complaint rate. Senders of more than 5,000 messages a day to Gmail must have SPF, DKIM and DMARC (at least p=none), alignment with the "From" domain, and one-click unsubscribe for marketing messages.

Microsoft followed in 2025: since May 5, 2025, Outlook.com, Hotmail and Live.com reject mail from senders of more than 5,000 messages a day that doesn't meet the SPF, DKIM and DMARC requirements, with error 550 5.7.15.

Your company may not send 5,000 emails a day, but that changes less than you'd think. Spam filters increasingly weigh authentication for every sender, and a message with no DKIM signature and no DMARC looks suspicious no matter how legitimate it is. And without DMARC, nothing stops a scammer from sending an "invoice" from your domain to your clients — a classic scenario we cover in 10 Ways to Spot a Phishing Email.

Step by step: a safe DMARC setup

The most common mistake is reading that "you need DMARC with reject," switching it on immediately — and the next day the invoices from your accounting software stop arriving. The right approach is gradual.

Step 1: Inventory every sender

Before you touch DNS, list everything that sends email with your domain in the "From" field. Typically that includes:

Your main mailbox provider — Microsoft 365, Google Workspace or hosting mail
Your website's contact form and notifications (WordPress, online store)
Invoicing and accounting software
Your newsletter tool (Mailchimp, Brevo and others)
Your CRM, helpdesk system and online booking tools
Scanners, printers and devices that send email over SMTP

At least one sender almost always gets forgotten. That's exactly why the first phase of DMARC is monitoring only.

Step 2: One correct SPF record

Your domain must have exactly one SPF record that includes every legitimate service. Watch out for the 10 DNS lookup limit: each "include" counts as at least one, and some services perform several more internally. Go over 10 and the check returns an error, so SPF effectively stops working. If you use many services, some of them can send from their own subdomain, or you can rely primarily on DKIM.

Step 3: DKIM for every service

Enable DKIM separately in each platform. In Microsoft 365 that means two CNAME records and enabling signing in the security portal; in Google Workspace you generate a key in the Admin console and publish a TXT record. Newsletter and invoicing services usually provide their own records under "domain authentication" settings.

Step 4: DMARC with p=none and reports

Publish a DMARC record with a p=none policy and an address for aggregate reports (rua). This policy doesn't change delivery, but you start receiving daily XML reports from the major providers showing who is sending mail as you, and from where. Raw reports are hard to read, so specialized services are used to turn them into clear dashboards.

Step 5: Analyze and fix (2–6 weeks)

Review the reports: which legitimate sources are failing SPF or DKIM? Add them, fix the records and wait for fresh data. This is usually where the forgotten invoicing system or the old office scanner shows up.

Step 6: Quarantine, then reject

Once all legitimate senders pass, move to p=quarantine — first for a share of messages using the pct tag (for example pct=25), then for all of them. After a few more weeks without issues, switch to p=reject. Only then is your domain truly protected from spoofing.

The most common mistakes

Two SPF records. For example an old one from your web host and a new one for Microsoft 365. Two records make SPF invalid — merge them into one.
Using "+all". This literally authorizes the entire internet to send as you. Use "-all" or "~all".
A forgotten sender. Moving to reject before the reports show every legitimate system passing.
DKIM only for the main mailbox. Newsletters and invoices go unsigned and fail under a strict policy.
DMARC without rua. With no reports you're flying blind and never find out when something breaks.
"Set and forget." Every new service (a new CRM, a new e-commerce platform) must be added to SPF and DKIM.

How to check your domain

Free online tools let you enter your domain and see whether it has SPF, DKIM and DMARC records and whether they're syntactically correct. Search for "DMARC checker" or "SPF record check" — the major DMARC service providers all offer such lookups.

Even more precise is reading a message's headers. In Gmail, open an email from your own domain, choose "Show original," and you'll see SPF, DKIM and DMARC lines with a PASS or FAIL status. In Outlook the same information is in the message properties, in the Authentication-Results line. If anything says FAIL, you have work to do.

Email domain protection checklist

A list of every system that sends from your domain
Exactly one SPF record, no "+all", under 10 DNS lookups
DKIM enabled for each service separately
A DMARC record with an rua address for reports
At least a few weeks of monitoring with p=none
A gradual move to quarantine and then reject
Periodic report reviews, and a check whenever you add a new service
Team training — technical protection doesn't replace vigilance (10 essential cybersecurity measures)

Frequently Asked Questions

Will DMARC stop all spam and phishing?

No. DMARC stops scammers from using your exact domain in the "From" field. Emails from lookalike domains (with a swapped letter, for example) or free webmail accounts aren't blocked by it, so staff training remains important.

We're a small company — do we need DMARC?

Yes. The 5,000-messages-a-day requirements target bulk senders, but spam filters assess authentication for everyone. Small businesses are also a frequent target of fake invoices sent to their clients, and DMARC at p=reject is the only real protection against that.

How long does a full DMARC setup take?

Publishing the records takes an hour or two. Safely moving from p=none to p=reject, however, usually takes anywhere from a few weeks to two or three months, depending on how many services send email on your behalf.

Can the setup break our own email?

It can, if you jump straight to reject without verifying every sender. That's why we start with p=none and reports — this policy doesn't affect delivery, it only gathers information.

How SNM Support can help

Setting up SPF, DKIM and DMARC looks like a few lines of DNS, but in practice it takes an inventory, report analysis and patience. We do this for businesses in Sofia and across Bulgaria: an email domain audit, discovery of every sender, correct SPF and DKIM records, and a gradual DMARC rollout all the way to reject — without interrupting your email. After that, we monitor the reports as part of our subscription IT support, so nothing breaks when you add your next service.

If your invoices are landing in spam, or you want to be sure nobody is sending email in your name, contact us for a free initial consultation.

SPF, DKIM and DMARC Setup: Why Your Emails Land in Spam and How to Protect Your Domain