SPF, DKIM and DMARC: what they are and how to set them up

Published on November 11, 2026 · The mitza.es team

“My email isn't reaching the client” is one of the most common IT problems in a small business, and it almost always has the same root: the server receiving the message can't verify that it really comes from your domain. That check depends on three DNS records: SPF, DKIM and DMARC. In early November 2026 the matter hit the tech press because of what happened with Outlook.com. We summarize what happened, what each record is and how to set them up sensibly.

What happened with Outlook.com in November 2026

From November 5 or 6, administrators of small domains began noticing bounces on emails sent to Outlook.com, Hotmail.com and Live.com addresses, with messages such as 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. The German publication heise linked it to domains with no DMARC record, with rejections even when SPF and DKIM were correct and with intermittent cases. Administrators of Microsoft 365 and of domains that already had DMARC also posted in the Microsoft community thread.

Microsoft's version, according to a moderator on its forum (incident EX1545193), is different: the problem was caused by “a recent update to antispam enforcement rules” that mistakenly flagged some legitimate emails as SPF violations. Microsoft reverted the change and on November 10 the service was listed as restored. Also, Microsoft has not announced any general DMARC requirement for small senders: what has remained in force since May 2025 is the obligation to have SPF, DKIM and DMARC (at least p=none) for domains that send more than 5,000 messages a day. In its own guidance, Microsoft says small senders “benefit” from these good practices, without imposing them.

What is left of all this? That publishing a minimal DMARC record is cheap insurance and that, if your emails bounce, it's worth checking the three records first. That said, the episode doesn't prove DMARC was the cause in every case: Microsoft's own explanation speaks of an error in its antispam rules.

What SPF, DKIM and DMARC are, in plain language

SPF (Sender Policy Framework): a list, published in your domain's DNS, of the servers that are allowed to send email on your behalf. It's like a roster of authorized mail carriers.
DKIM (DomainKeys Identified Mail): a digital signature added to every message. The receiver checks it against a public key that you publish in DNS, and so knows the message comes from who it says it does and hasn't been altered along the way.
DMARC: the policy that ties the two together. It tells the receiver what to do if SPF or DKIM don't match the visible “From:” address (nothing, quarantine or reject) and where to send you reports. This is where the idea of alignment comes in: the domain being authenticated must match the one the recipient sees.

All three are published as TXT records (or CNAME, in the case of DKIM, depending on the provider) in your domain's DNS zone. If you have already seen them in passing in our guide to Google Workspace or Microsoft 365 for business email, here we look at them in more detail.

What the records look like

Examples with a fictitious domain (replace yourdomain.com with your own):

SPF

A single TXT record at the root of the domain. For Microsoft 365 it usually looks like this, and for Google Workspace the included service changes:

yourdomain.com.   TXT   "v=spf1 include:spf.protection.outlook.com -all"
yourdomain.com.   TXT   "v=spf1 include:_spf.google.com ~all"   (Google Workspace: one or the other, not both)

There can be only one SPF record per domain, and SPF allows at most 10 DNS lookups: if you add many services, they have to be merged into the same record. ~all means “soft fail” and -all “hard fail”; start with the first if you're not sure.

DKIM

It isn't written by hand: it is generated in the console of your email service (Google Workspace, Microsoft 365, your newsletter tool, your online store…) and they give you one or two records to publish in DNS. It has to be enabled in every service that sends email with your domain.

DMARC

A TXT record on the _dmarc subdomain. The minimum to get started, with reports sent to a mailbox of yours:

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

p=none doesn't change what happens to your email: it only requests reports. rua is the address that will receive the aggregate reports. A DMARC record doesn't guarantee that everything passes: in addition, SPF or DKIM must be aligned with the visible domain.

How to set it up step by step

Make a list of everything that sends email with your domain: your email service, the website (contact forms), the online store, the invoicing tool, the CRM, the newsletters.
Publish a single SPF record that includes all those services.
Enable DKIM in each service and publish its records.
Publish DMARC with p=none and rua. That way you start receiving reports without putting legitimate email at risk.
Review the reports for two to four weeks (they can be long to read; there are free services that summarize them) to spot services that send on your behalf and that you had forgotten.
Raise the policy gradually: from p=none to p=quarantine and, once everything is clean, to p=reject. Microsoft and specialists agree on moving gradually.

How to check that it works

Query the records: on Windows, nslookup -type=txt _dmarc.yourdomain.com; on Linux or macOS, dig TXT _dmarc.yourdomain.com. Change the name to check SPF and DKIM.
Send yourself a test email to a Gmail account and open the message with the “Show original” option: SPF, DKIM and DMARC should appear as “PASS”.
Look at the Authentication-Results header of the emails you receive from others: it is where each server notes whether the check passed.
Test with different destinations: Gmail, Outlook.com and a customer's account.

If your emails bounce or go to spam

Read the bounce code. The error text (for example, 550 5.7.1 or 5.7.515) tells you which check failed and who rejected it.
Review the three records with the checks above and fix whatever fails: a duplicated SPF record and a forgotten service are common causes.
Don't resend the same email in a loop: it damages your domain's reputation.
Keep evidence (the full bounce message, the message ID and a sample in .eml format) so you can contact the recipient's support service, which is what the Microsoft moderator recommended in the November case.
If it is intermittent and your records are fine, it may be a problem on the receiving provider's side, like the one Microsoft rolled back on November 10: wait, repeat the test and check the service status.

Common mistakes

Publishing two SPF records on the same domain: the result is a permanent error and SPF stops validating.
Forgetting services that send email on your behalf: invoicing, CRM, newsletters, the website itself.
Switching to -all or to p=reject without having reviewed the reports first.
Sending the website's contact forms with the server's mail function, with no authentication: it is better to use authenticated sending (SMTP) or a service authorized in SPF and DKIM.
Not protecting subdomains or domains you don't use for email.

Beyond delivery: stopping people from impersonating your domain

With DMARC at quarantine or reject, fake emails that use your domain have a harder time reaching the inbox of whoever receives them, which complicates frauds such as the ones we explain in the scams that impersonate your online store or in the IBAN change fraud. It doesn't eliminate the risk, because attackers can also use domains that look like yours, but it closes a very common door.

What Google, Yahoo and Microsoft require

Google and Yahoo: since 2024, SPF, DKIM and DMARC for anyone sending more than 5,000 messages a day to their users.
Microsoft (Outlook.com): since May 2025, SPF, DKIM and DMARC with at least p=none for domains that send more than 5,000 messages a day. According to its note, non-compliant email would first be sent to the junk folder and rejected later, with a date still to be announced. For all other senders it isn't mandatory, but it is recommended.
If your company sends newsletters or campaigns to many recipients, even if you don't reach that figure yourself, the sending service you use may well be subject to these requirements.

Quick questions

Is DMARC mandatory for a small business?

There is no general obligation for small volumes, but it is a recommended practice and an increasingly common one. With p=none you start with no risk.

Can DMARC make me lose email?

With p=none, no. The risk appears when moving to quarantine or reject if there are legitimate services that haven't been authorized. That's why you review the reports first.

How long does it take for a DNS change to take effect?

It depends on the record's cache time (TTL). It can be anywhere from minutes to a few hours; occasionally, a bit longer.

Do I have to do it myself or does my email provider do it?

The record is published in your domain's DNS, so it depends on who manages it (your domain, hosting or IT provider). If you don't know who that is, there is a guide in domain and hosting: what they are and how to choose.

How we can help at Mitza

We review your domain's records, set up SPF, DKIM and DMARC gradually and check that everything that sends email on your behalf is authorized. See our IT maintenance for small businesses or tell us about your case on the contact page.

SPF, DKIM and DMARC: what they are, how to set them up and what to do if your company's emails don't arrive (the Outlook.com case)